ソフトウェア開発者にとって、自分のマシンで動作するコードを書くことさえ困難です。しかし、それができたとしても、そこから価値を生み出すソフトウェアに至るまでには長い道のりがあります。なぜなら、ソフトウェアは本番環境にある場合にのみ価値を生み出すからです。私のソフトウェアデリバリーに対する哲学の本質は、常に本番環境に投入できる状態にあるソフトウェアを構築することです。このソフトウェアがデリバリーできる状態にあるかどうかをテストするデプロイメントパイプラインを継続的に実行しているため、これを継続的デリバリーと呼びます。

継続的インテグレーションとは、チームの各メンバーが、少なくとも毎日、同僚の変更と共に自分の変更をコードベースにマージするソフトウェア開発プラクティスです。これらの統合のそれぞれは、自動ビルド（テストを含む）によって検証され、統合エラーをできるだけ早く検出します。チームは、このアプローチにより、デリバリーの遅延のリスクが軽減され、統合の労力が削減され、新しい機能を迅速に強化するための健全なコードベースを促進するプラクティスが可能になることを発見しています。

最新のソースコード管理システムは、ソースコードでブランチを簡単に作成できる強力なツールを提供します。しかし、最終的にはこれらのブランチをマージする必要があり、多くのチームが絡み合ったブランチの処理に膨大な時間を費やしています。複数の開発者の作業を統合し、本番リリースへのパスを整理するために、チームが効果的にブランチを使用できるいくつかのパターンがあります。上位のテーマは、ブランチを頻繁に統合し、最小限の労力で本番環境にデプロイできる健全なメインラインに焦点を当てることです。

継続的デリバリーの概要を1時間かけて説明します。トピックには、継続的デリバリーの正当性、デプロイメントパイプライン、継続的インテグレーション、DevOps、およびデプロイメント戦略が含まれます。ハイライトは、Jezによるリリース候補の人格化であり、ギリシャ神話の英雄として描かれています。

機械学習アプリケーションは私たちの業界で人気が高まっていますが、それらを開発、展開、そして継続的に改善するプロセスは、ウェブサービスやモバイルアプリケーションなどの従来のソフトウェアと比較してより複雑です。それらは、コード自体、モデル、そしてデータの3つの軸で変化を受けます。それらの動作は複雑で予測が困難なことが多く、テスト、説明、および改善が困難です。機械学習のための継続的デリバリー（CD4ML）とは、機械学習アプリケーションに継続的デリバリーの原則と実践を取り入れる規律です。

DevOps文化の中でコンプライアンス要件を満たすために必要なセキュリティコントロールと監査機能を統合することで、CI/CDパイプラインの自動化を活用できますが、組織が拡大するにつれて独自の課題が生じます。選択した実装によって引き起こされる二次的な影響と意図しない結果を理解することは、効果的で安全でスケーラブルなソリューションを構築するための鍵となります。

ソフトウェアシステムにおけるオブザーバビリティは常に価値があり、クラウドとマイクロサービスの時代になってさらに重要になっています。しかし、システムに追加するオブザーバビリティは、低レベルで技術的な性質のものであることが多く、多くの場合、さまざまなログ、インストルメンテーション、分析フレームワークへの面倒で冗長な呼び出しでコードベースを散らかす必要があります。この記事では、この問題を解決し、クリーンでテスト可能な方法でビジネスに関連するオブザーバビリティを追加できるパターンについて説明します。

フィーチャートグル（フィーチャーフラグとも呼ばれる）は強力な手法であり、コードを変更せずにシステムの動作を変更できます。さまざまな使用カテゴリに分類され、実装と管理を行う際にはそのカテゴリを考慮することが重要です。トグルは複雑さを導入します。スマートなトグル実装プラクティスと適切なツールを使用してトグル構成を管理することで、その複雑さを抑えることができますが、システム内のトグルの数を制限することも目指すべきです。

従来、QAは本番環境へのリリース前にソフトウェアをテストし、リリースの準備ができているかどうかを確認することに重点を置いていました。しかし、近年、最新のQA組織は、本番環境で実行されているソフトウェアにも注目しています。ログやその他の監視ツールを分析することにより、開発組織に強調表示する品質上の問題を見つけます。このアプローチは、継続的デリバリーを使用して新しいバージョンのソフトウェアを迅速かつ確実に本番環境に投入する組織で特に効果的です。

2010年のQConサンフランシスコでのJez Humbleと私へのインタビュー

自動回帰スイートはソフトウェアプロジェクトで重要な役割を果たし、本番環境での欠陥を削減するだけでなく、進化的な設計にも不可欠です。開発チームと話していると、非決定論的テスト、つまり、時として成功し、時として失敗するテストの問題についてよく耳にします。制御されないままにしておくと、非決定論的テストは自動回帰スイートの価値を完全に破壊する可能性があります。この記事では、非決定論的テストに対処する方法の概要を示します。最初は隔離することで、他のテストへのダメージを軽減できますが、すぐに修正する必要があります。そのため、非決定性の一般的な原因である隔離の不足、非同期動作、リモートサービス、時間、およびリソースリークに対する治療法について説明します。

この動画（12分）で、Mike Masonと私はフィーチャーブランチの危険性とその代替案について話します。

Rakeは、makeやantと同様の目的を持つビルド言語です。makeやantと同様にドメイン固有言語ですが、これら2つとは異なり、Ruby言語でプログラムされた内部DSLです。この記事では、Rakeを紹介し、このウェブサイトの構築にRakeを使用することで得られた興味深い点について説明します。依存関係モデル、合成タスク、カスタムビルドルーチン、およびビルドスクリプトのデバッグ。

アジャイルプロジェクトに関する最もよくある質問の1つは、別のチームへの引き継ぎをどのように処理するかです。開発チームが離れてサポートチームにサポートを引き継いだ場合、アジャイルプロジェクトは計画駆動型プロセスよりもはるかに少ないドキュメントを作成する傾向があるため、どのように対処しますか？

私の同僚と私がクライアントに強く勧めている目標の1つは、完全に自動化されたデプロイメントプロセスです。デプロイメントを自動化することで、ソフトウェアが「完了」してからその価値を実現するまでの間に発生する摩擦と遅延を軽減できます。Dave FarleyとJez Humbleは、このトピックに関する書籍「継続的デリバリー」を完成させつつあります。継続的インテグレーションに一般的に関連付けられている多くのアイデアに基づいて、ソフトウェアを迅速に本番環境に投入し、何かを実行できるようにする能力をさらに推進します。彼らのブルーグリーンデプロイメントに関するセクションは、過小評価されている手法の1つとして私の目を引いたので、ここで簡単に概要を説明したいと思います。

「抽象化によるブランチング（Branch by Abstraction）」とは、大規模なソフトウェアシステムへの変更を段階的に行う手法です。この手法を用いることで、変更が進行中であってもシステムを定期的にリリースできます。

継続的インテグレーションの利点については何度も話してきました。このような環境を構築するには、継続的インテグレーションサーバーとソースコード管理システムが必要です。プロジェクトを円滑に進めるためには、バグ追跡などのための問題追跡システムと、あらゆる種類のプロジェクト知識を記録するためのWikiも役立ちます。

カナリアリリースとは、新しいソフトウェアバージョンを本番環境に導入するリスクを軽減するための手法です。変更をインフラストラクチャ全体に展開し、すべての人が利用できるようにする前に、少数のユーザーに段階的に展開することでリスクを低減します。

最新のアプリケーションサーバーの宣伝されている機能の1つに、クラスタにおけるフェイルオーバーがあります。クラスタリングはアプリケーションの信頼性を向上させます。サーバーの1つがダウンしても、顧客にサービスを提供できる他のサーバーがあります。フェイルオーバーはさらに信頼性を高めることができます。インタラクション中にサーバーがダウンした場合、クラスタはそのインタラクションを別のサーバーに移動できます。

しかし、これが問題になる場合があります。

ソフトウェアシステムが、異なるプロセスで実行されている、おそらくネットワークを介して異なるマシン上にあるソフトウェアへのリモート呼び出しを行うことは一般的です。インメモリ呼び出しとリモート呼び出しの大きな違いの1つは、リモート呼び出しは失敗したり、応答がないままハングしたりすることがあり、タイムアウト制限に達するまで続きます。さらに悪いことに、応答のないサプライヤーに多くの呼び出し元がいる場合、重要なリソースを使い果たして、複数のシステムにわたってカスケード障害が発生する可能性があります。マイケル・ナイガードの優れた著書「Release It」では、この種の壊滅的なカスケードを防ぐためのサーキットブレーカーパターンが普及しました。

サーキットブレーカーの基本的な考え方は非常にシンプルです。保護された関数呼び出しをサーキットブレーカーオブジェクトでラップします。これは、障害を監視します。障害が特定のしきい値に達すると、サーキットブレーカーがトリップし、それ以降のサーキットブレーカーへのすべての呼び出しは、保護された呼び出しがまったく行われずにエラーで返されます。通常、サーキットブレーカーがトリップした場合の何らかの監視アラートも必要になります。

(CFEngine、Puppet、またはChefなどの)自動化された設定ツールを使用すると、サーバーの要素の設定を記述するレシピを提供することにより、SnowflakeServersを回避できます。設定同期は、これらの仕様を定期的なスケジュールで、または変更時に、サーバーのライフサイクル全体を通して継続的に適用します。誰かがツール以外でサーバーに変更を加えた場合、次回サーバーが同期されたときに、中央で指定された設定にロールバックされます。設定変更が必要な場合は、設定仕様（レシピ、マニフェスト、または特定の設定ツールが呼ぶもの）で行われ、インフラストラクチャ全体の関連するすべてのサーバーに適用されます。

継続的デリバリーとは、いつでも本番環境にリリースできるような方法でソフトウェアを構築するソフトウェア開発手法です。

継続的デリバリーを行っている場合

• ソフトウェアは、ライフサイクル全体でデプロイ可能です。
• チームは、新機能の開発よりもソフトウェアのデプロイ可能な状態を維持することを優先します。
• 誰かがシステムに変更を加えた場合、いつでも迅速に自動化されたフィードバックを得て、本番環境への準備状況を確認できます。
• ソフトウェアの任意のバージョンを、オンデマンドで任意の環境にプッシュボタンデプロイできます。

継続的インテグレーションは、ソフトウェア開発で人気のある手法です。カンファレンスでは多くの開発者がその使用方法について話し合い、継続的インテグレーションツールはほとんどの開発組織で一般的です。しかし、私たちは、まともな手法には認定プログラムが必要であることを知っています。そして幸いなことに、それは存在します。継続的デリバリーとDevOpsの第一人者によって開発されたこのプログラムは、驚くほど迅速に管理でき、その結果に対して非常に洞察力があることで知られています。かなり成熟していますが、十分に知られていません。そのため、この手法のファンとして、この認定プログラムを私の読者と共有することが重要だと思います。継続的インテグレーションの認定を受ける準備はできていますか？そして、テストを受けることで明らかになる衝撃的な真実をどのように対処しますか？

機能をダークローンチするとは、新しいバックエンドの動作または変更されたバックエンドの動作を行い、既存のユーザーから呼び出すことを意味します。ユーザーが呼び出されていることに気付くことができないように行います。これは、新しい機能を公開する前に、システムへの追加負荷とパフォーマンスへの影響を評価するために行われます。

最近気付いた興味深い対比があります。規模の似た（〜10万LOC）2つのエンタープライズアプリケーションプロジェクト、同様の環境（Javaと.NET）。片方は1時間で完全なビルドとテストを実行できますが、もう片方は2〜3分かかります。

自動化されたビルドとテスト環境の課題の1つは、迅速なフィードバックを得るためにビルドを高速化したいということです。しかし、包括的なテストを実行するには時間がかかります。デプロイメントパイプラインは、ビルドを段階的に分割することでこの問題に対処する方法です。各ステージは、通常は追加の時間を費やすことで、信頼性を高めます。初期のステージでは、ほとんどの問題を迅速に検出できます。一方、後のステージでは、より遅く、より徹底的な調査を行うことができます。継続的デリバリーの中心的な部分です。

アジャイルソフトウェア開発は、要件分析、テスト、開発間のサイロの一部を解消しました。デプロイ、運用、保守は、ソフトウェア開発プロセスの他のアクティビティから同様の分離に苦しんでいる他のアクティビティです。DevOpsムーブメントは、これらのサイロを取り除き、開発と運用間の協力を促進することを目的としています。

回帰バグとは、しばらく前から存在するソフトウェアの機能に新しく発生したバグです。それらを追跡する際には、どのソフトウェアの変更によってそれらが発生したのかを把握することが通常は重要です。その変更を見ることで、バグの位置と修正方法に関する貴重な手がかりを得ることができます。この調査方法にはよく知られた用語はありませんが、私はそれをDiffデバッグと呼んでいます。

フィーチャーブランチとは、開発者が新しい機能の作業を開始したときにブランチを作成するソースコードのブランチパターンです。開発者はこのブランチで機能に関するすべての作業を行い、機能が完了したらチームの残りの部分と変更を統合します。

フィーチャーブランチを支持する最も一般的な議論の1つは、単一のリリースサイクルよりも長くかかる保留中の機能のためのメカニズムを提供することです。2週間ごとに本番環境にリリースしていますが、完了までに3か月かかる機能を構築する必要があるとします。半実装された機能をリリースに公開せずに、メインラインで全員が作業を続けられるように継続的インテグレーションを使用するにはどうすればよいでしょうか？私たちはしばしばこの問題に遭遇し、フィーチャートグルはそれを処理するための便利なツールです。

私のお気に入りの名言の1つは、「痛ければ、より頻繁に行う」です。表面上はナンセンスに見えるという嬉しい特性がありますが、深く掘り下げると価値のある意味が得られます。

(CFEngine、Puppet、またはChefなどの)自動化された設定ツールを使用すると、サーバーの設定方法を指定し、新規および既存のマシンをコンプライアンスに準拠させることができます。これは、壊れやすいSnowflakeServersの問題を回避するのに役立ちます。このようなツールは、必要に応じて破棄して再構築できるPhoenixServersを作成できます。イミュータブルサーバーはこのアプローチの論理的な結論であり、一度デプロイされると変更されず、新しい更新されたインスタンスに置き換えられるだけです。

どの職業にも言えることですが、ソフトウェア開発にも、しばしば忘れられ、通常は無視されますが、まさに悪いタイミングで裏目に出る癖のある活動があります。その一つがデータ移行です。

インフラ・アズ・コードとは、コンピューティングおよびネットワークインフラストラクチャをソースコードで定義し、それを他のソフトウェアシステムと同様に扱うアプローチです。このようなコードはソース管理に保管して監査可能性と再現可能なビルドを可能にし、テストプラクティスと継続的デリバリーの完全な規律に従うことができます。これは、ここ10年間、増え続けるクラウドコンピューティングプラットフォームに対処するために使用されてきたアプローチであり、今後、コンピューティングインフラストラクチャを処理する主要な方法となるでしょう。

ソフトウェア開発チームは、可能な限り頻繁に作業を統合すれば、生活がはるかに楽になることを発見します。また、頻繁に本番環境にリリースすることも価値があると認識しています。しかし、チームは開発途中の機能をユーザーに公開したくありません。この緊張に対処するための便利なテクニックは、すべてのバックエンドコードを構築して統合しますが、ユーザーインターフェースは構築しません。機能は統合してテストできますが、UIは最後にキーストーンのように追加されるまで保留され、ユーザーに公開されます。

私は継続的インテグレーションの熱烈なファンです。これは比較的簡単なプラクティスですが、ほとんどの開発チームにとって大きな違いをもたらす可能性があります。しかし、ほとんどのプラクティスと同様に、欠点^H^H^H^H^H改善の余地があります。ポール・デュバル（このテーマに関するまもなく標準的な書籍の著者）は、最近これらの1つを指摘しました。コミットビルドが壊れると、チーム全体が影響を受け、修正されるまで潜在的に遅れる可能性があります。

ある日、私は運用のための認証サービスを開始するという空想をしました。認証評価は、同僚と私が企業のデータセンターに出向き、野球のバット、チェーンソー、ウォーターピストルを使って重要な本番サーバーをいじくり回すことから成ります。評価は、運用チームがすべてのアプリケーションを再び稼働させるのにかかる時間に基づきます。

プルリクエストは、githubによって普及したメカニズムであり、特にオープンソースプロジェクトのコンテキストにおいて、作業の統合を容易にするために使用されます。貢献者は、中央リポジトリのフォーク（クローン）で自分の貢献に取り組みます。貢献が完了したら、プルリクエストを作成して、中央リポジトリの所有者に、自分の作業がメインラインにマージする準備ができたことを通知します。ツールは、リクエストを受け入れる前に、貢献のコードレビューをサポートし、奨励します。プルリクエストはソフトウェア開発で広く使用されるようになりましたが、批評家は、継続的インテグレーションを妨げる統合摩擦の追加を懸念しています。

人々はコードレビューについて考えるとき、通常は開発チームのワークフローにおける明示的なステップを考えます。今日では、プルリクエストで行われるプリインテグレーションレビューが、コードレビューで最も一般的なメカニズムであり、多くの人が、プルリクエストを使用しないとコードレビューを行う機会がすべてなくなることを無意識に考えているほどです。このような狭いコードレビューの見方は、多くの明示的なレビューメカニズムを無視するだけでなく、おそらく最も強力なコードレビューテクニック、つまりチーム全体によって行われる永続的な洗練を無視しています。

継続的インテグレーションの支持者が持っている一般的な仮定の1つは、ビルドは再現可能であるということです。これは、作業中のシステムの古いバージョンをいつでも取得し、そのときと同じ方法でソースからビルドできることを意味します。

自己テストコードとは、リファクタリングで、機能的なソフトウェアと組み合わせて包括的な自動テストを作成するプラクティスを指すために使用した名前です。うまく行われると、テストを実行する単一の コマンドを呼び出すことができ、これらのテストによってコードに隠れているバグが明らかになるという確信を持つことができます。

私の同僚と私がフィーチャブランチについて話すのを聞いた人は、私たちがそのパターンを高く評価していないことを知っています。私たちの反対の重要な部分は、ブランチングは簡単だが、マージは難しいという観察です。時々聞く議論の1つは、最新のバージョン管理ツールによってマージが十分に簡単になり、フィーチャブランチが価値を持つということです。

本番サーバーを稼働し続けることは、厄介な仕事になる可能性があります。オペレーティングシステムとその他の依存ソフトウェアが適切にパッチされて最新の状態に保たれていることを確認する必要があります。ホストされているアプリケーションは定期的にアップグレードする必要があります。環境を効率的に実行し、他のシステムと適切に通信できるように、構成変更が定期的に必要になります。これには、コマンドラインの呼び出し、GUI画面間のジャンプ、テキストファイルの編集を組み合わせる必要があります。

その結果、スキーリゾートには良いが、データセンターには悪いユニークなスノーフレークが作成されます。

DevOpsレポートの状態は、年間報告書であり、調査データの統計分析を使用して、ソフトウェアデリバリー組織の効果的なプラクティスを決定します。その主な執筆者は、Nicole Forsgren、Jez Humble、Gene Kimです。

合成監視（セマンティック監視とも呼ばれる）は、アプリケーションの自動テストのサブセットを定期的にライブ本番システムに対して実行します。結果は監視サービスにプッシュされ、障害が発生した場合にアラートがトリガーされます。このテクニックは、自動テストと監視を組み合わせて、本番環境で失敗したビジネス要件を検出します。

人々がエクストリームプログラミングについて話すとき、彼らはしばしば、その適応的な計画スタイルや進化的なアプローチ設計などのことに焦点を当てます。私が特に興味を持っている小さな成長傾向の1つは、非常に低い欠陥率（つまり、月に1つ未満の本番バグ）を持つXPプロジェクトの小さな数の増加です。